ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group93a.txt/000018_icon-group-sender _Fri Jan 15 11:09:13 1993.msg

Internet Message Format | 1993-04-21 | 4KB

Received: by cheltenham.cs.arizona.edu; Fri, 15 Jan 1993 06:26:01 MST
Date: Fri, 15 Jan 1993 11:09:13 +0100
From: [e-mail] (Michael Sperber)
Message-Id: <[e-mail]>
To: [e-mail]
In-Reply-To: (Steve Wampler)'s message of Wed, 13 Jan 93 18:26:28 +0100
 <[e-mail]*[e-mail]>
Subject: Pattern matching in Icon?
Status: R
Errors-To: [e-mail]

Steve Wampler writes:
>Ah, I think I fully understand.  I think this would take quite a
>bit of changes to Icon to work - consider that in Icon, 'syntax_tree'
>is just a function call, the user could (in a perverse moment), do
>
>    syntax_tree := f
>
>and the case statement suddenly changes.  I think the problem could
>be resolved in specific instances, but it would greatly complicate the
>case statement:
>
>  (if this function is a record constructor, then don't evaluate it,
>  it's a pattern...)
>
>but I don't see how to do it in general.  I think you would have
>to restrict case clauses to *only* literals and patterns, which is
>more restrictive than now (not that it would likely impact many people).
>
>In the present form, you can still do it by
>building your own set of pattern-matching operations (since the
>runtime system has to have something to do it anyway):
>
>   case s of {
>     match_syntax_tree("let",s) : ...
>     match_syntax_tree("apply",s) :...
>
>which would require you (as the programmer) to establish the pattern-matching
>rules - though to me that's a net win, since I might want to do some form
>of pattern matching that the language implementor didn't anticipate (such
>as some form of 'symantic' pattern matching).

The syntactic issue I glitched on was to use the standard case
statement for pattern matching.  How about having a "pattern_case" (or
a "match ... of") or some separate thing, where only patterns are
allowed (meaning: only direct data structure constructors).

But I think I still haven't been able to get through fully with my
ideas.  The above construct would not do what I meant.  Also, Bob
Alexander writes:

>Is this an Icon-esque paraphrase of the structure you want, or something
>close?  Or do I completely fail to understand the concept?
>
>    case type(s) || "::" || s[1] of {
>      "syntax_tree::let": {
>    s[2] := args
>    ...
>      }
>      "syntax_tree::apply": {
>    s[2] := args
>    ...
>    }
>
>(The "::" is an arbitrary separator).  This permanently alters the second
>field of "s" -- if that's not okay it could be cured by working on a
>copy of s.

So I'll try yet again:

record syntax_tree(operator, arguments)

match <expression> of {
  syntax_tree("let", a) : {
  # Now, we get here if <expression> evaluates to a
  # syntax_tree record with the operator component "let".
  # In this branch, a is bound to the arguments componen
  # of <expression> (NOT the other way around!).
  }
  ...
}

In functional languages, this greatly simplifies operating on any kind
of recursive data structures, which syntax trees, say, happen to be.
That is exactly why many people consider {SML, Hope, Miranda} ideally
suited for compiler writing.  Icon does not have this feature, but it
was designed with compiler design in mind.  It is better suited for
the early stages of a compiler, but worse for actual program
transformation and code generation.

Cheers :-> Chipsy